home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / tsql / doc / tsql.mail / 000048_edrbtsn@cs.indiana.edu _Tue Mar 23 10:20:58 1993.msg < prev    next >
Text File  |  1996-01-31  |  3KB  |  58 lines
  1. Message-Id: <199303231646.AA20166@optima.cs.arizona.edu>
  2. Received: from bigeye.cs.indiana.edu by optima.cs.arizona.edu (5.65c/15) via SMTP
  3.     id AA20166; Tue, 23 Mar 1993 09:46:06 MST
  4. Received: by bigeye.cs.indiana.edu
  5.     (5.65c/9.4jsm) id AA07630; Tue, 23 Mar 1993 10:20:59 -0500
  6. From: "Ed Robertson" <edrbtsn@cs.indiana.edu>
  7. Subject: schema
  8. To: tsql@cs.arizona.edu (TSQL working group)
  9. Date: Tue, 23 Mar 1993 10:20:58 -0500 (EST)
  10. X-Mailer: ELM [version 2.4 PL21]
  11. Mime-Version: 1.0
  12. Content-Type: text/plain; charset=US-ASCII
  13. Content-Transfer-Encoding: 7bit
  14. Content-Length: 2338      
  15.  
  16. There have been several suggestions for a "phasing" of the benchmark
  17. queries.  In particular, Christian has identified the following
  18. as additions we should want to consider:
  19.  
  20. |       (a) it should be possible to use the same relation more than
  21. |       once in each query
  22. |       (b) queries involving aggregation facilities should be included
  23. |    (c) it should be possible to ask queries involving valid time
  24. |        and user-defined time
  25.  
  26. However, I'd like to suggest that we put as much into the SCHEMA as we
  27. could think of NOW.  Maybe I've gotten frustrated from years of teaching,
  28. since I always have trouble with students who want to rush ahead before
  29. the schema is fully considered.  But my intuitive feeling is that having
  30. the same schema for all the phases of query design is a good idea.  That
  31. insures that all queries are specified in the same context.
  32.  
  33. The additional attributes I've seen suggested:
  34.     gender (time invariant - modern medicine notwithstanding)
  35.     birthdate (user defined ??? )
  36.     skill (multivalued)
  37.  
  38. Concerning the issue of the gender attribute, Christian suggests
  39. | Inclusion of time-invariant (same as "non-temporal") attributes has
  40. | been proposed. It is my feeling that the motivation for this is to
  41. | obtain a schema better suited for queries involving aggregates (?).
  42. However, our feeling is also that it's a good idea to be able to make
  43. subtle distinctions, such as between "list all managers ever earning
  44. more than $50000" and "list all women ever earning more than $50000".
  45. On a system with no built-in temporal support the first query would
  46. certainly be more difficult than the second, so one might expect that
  47. a poorly designed temporal system would also exhibit differences in
  48. phrasing these queries.
  49.  
  50. I'd also like to point out the difficulties with trying to classify
  51. queries by operations -- such classifications are highly dependent
  52. on other aspects of the implementation.  For example, Christian's
  53. item (a) above looks like it doesn't apply to the query "list employees
  54. who ever worked in shipping and now earns at least $40000".  But if tuple
  55. time-stamping, rather than attribute time stamping, is used, then it
  56. would be necessary to do a join to match up current salaries and
  57. past departments.  (Of course part of the trouble is that little word
  58. "ever," which will certainly confound us in the future.)